Trivy scan found the following vulnerabilities:

• HIGH openssl: Incorrect cipher key and IV length processing in libcrypto3 v3.1.3-r0. Fixed in v3.1.4-r0
• HIGH openssl: Incorrect cipher key and IV length processing in libssl3 v3.1.3-r0. Fixed in v3.1.4-r0

Summary from the offline discussion between @chaudum and @vlad-diachenko

The current implementation of getting the fingerprint ownership works generically no matter how many tokens an instance has in the ring, and therefore how many token ranges.
The problem, however, is that if an instance has multiple token ranges, the fingerprints from both ranges are added to the same job, resulting in a min and max fingerprint for the job that spans both the token ranges of the instance plus everything in between. This would result in unnecessary downloads of blocks.

At the moment, bloom compactors are configured with 1 token per instance, which means that there is always exactly 1 instance that has two token ranges (one from lastToken+1 to MaxUint32, and one from 0 to firstToken).

There are two options then:

1. Create a job for each token/fingerprint range of the instance. This will work with any number of tokens per instance.
2. Use the order of instances based on their first token in the ring and split the ring's token range into n equal ranges and assign them in order of the instances. This would create equal token ranges for each instance, even if the tokens in the ring are not evenly distributed.

There are two options then:

1. Create a job for each token/fingerprint range of the instance. This will work with any number of tokens per instance.
2. Use the order of instances based on their first token in the ring and split the ring's token range into n equal ranges and assign them in order of the instances. This would create equal token ranges for each instance, even if the tokens in the ring are not evenly distributed.

Discussed offline. I also think the second approach is going against the nature of ring. It is fragile to the changes in the number of tokens and requires future operators of the service to know the ring implementation. One of the advantages of the first approach as a result will create a job per range, which will nicely reduce job's responsibility. In second approach we better introduce a further divide up for the job, otherwise the work may get quite big. I'm happy for us to try and see both approaches.
Implementation so far lgtm.